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(57) Abstract 

A mechanism for recognizing and processing compressed hypertext markup language (HTML) data is provided. According to one 
aspect of fl»e present invention, compressed HTML is dovmloaded by an application by employing a protocol interceptor (350), such as an 
instance of a pluggable protocol handler (340) (also r^ened to as a moniker), a plug-^n, a h^er application, or die like. Hie application 
(VXS) receives a request for a resource located on a remote server (120) that contms com{nessed HTML data. The application (300) 
invokes an appropriate protoed intercqrtor (350) to downloa d the requested resource. Hie appropriate protocol inlerc^tar (350) may be 
determined with reference to a protocol m^ (360) contabiing a ragistned asynchronaus phiggable protocol, pluggable name-apace handlers, 
and/or MIME fihars. In aiiyeveiit, Oie protocol interceptor Q50) requests the resource fiom be remot e gerv enequests tiie resource from die 
remote server (120) by way of a network tiansfbr protocol, such as Hypertext Tran sfer Protocd (HTIP), File ttansfer Protocol (FTP), 
gopher, Simple Man Ttansfer Protocol (SMIT), or similar application protocol. Compressed HTML data is subsequently reedved 1^ the 
protocol interceptor (350) firam die remote server. Tlie protocol interceptor (350) decompiesses the compressed HTML data and provides 
HTML data to the plication (300) which may dien be rendered by die application. 
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iDENTinCATION AND PROCESSING OF 
COMPRESSED HYPERTEXT MARKUP LANGUAGE (HTML) 

FIELD OF THE INfVENTION 

The invention relates generally to the field of Web-based applications. 
More particularly, the invention relates to processing HTML data that is stored on 
a server in a compressed founat 

BACKGROUND OF THE INVENTION 

The use of the Internet, and particularly the World Wide Web (the Web) 
has increased substantially in recent years. The Web is a coUection of finmatted 
hyp»text pag^ located on nomerous computers around the world that are 
logicaUy connected by the Intunet. AlflioughtheWebhasintfaepastbeena 
scniice of primarily sdratific infonnation, it is now a valuable resource for 
infomadon relating to almost any subject, including business, entertainmoit, 
travel, and education, to name just a few. 

The architecture of the Wd> follows a convoitional clioit-snver model. 
The tarns "clienr and "server" are used to refer to a counter's general lole as a 
requester of data (die clknt) or provider of data (the server). Web clients and 
Web servers ccnnmunicate usmg a protocol such as Hypertext Transfer Protocol 
(HTTP). HTTP is an £q>plication-level network transfer protocol that, amcmg 
other things, facilitates die request and the transfer of data between Web clients 
and Web servers. 

In the Web environment, Web browsers, programs that can dotwnload and 
render Web documents, reside on clients and the Web document^ (also referred to 
as Web pages) reside on servers. Web documents are typically encoded with a 
tag-based notation language called Hypertext Markup Language (HTML). 

Many different file formats are encountered on the Web such as HTML 
files, plain text files, word processing documents, graphics, video, audio, software 
s^licadons, and many others. Currently, a significant portion of the content of 
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the Web resides on servers, and is consequently transmitted to clients, in an 
uncompressed fortnat. While many graphic and audio file formats are typically 
compressed, such as Graphics Interchange Format (GIF) and Real Audio files, 
HTML files are not In addition to the clear waste of disk space on servers, many 
dovmtteam inefficiencies are a result of uncompressed HTML data transmission, 
including the depletion of intangible resources such as Internet bandwidth and 
user time. 

This oversight regarding HTML files may be due in part to the fact that no 
standardized mechanism has been agreed upon by content provides for 
identifying compressed contract as such. Additionally, the focus a£ traditional 
solutions is directed toward providing hardware that can inx>cess data more 
quickly, such as faster modems and processors. 

Howevor, now that next generation Web browsers, sudi as Microsoft 
Intonet Exploxer'"** 4.0, are providing pluggable protocols and other mechanisms 
for legisteriog customized Uniform Resonice Locator (URL) protocol handlers, it 
is desirable to expUM these tools to allow servers to store and transmit 
conqnessedHTML. AdditionaUy, it is advantisgeous for clioit programs to 
recognize compressed content, and to perform sqppropriate processing including 
dioit-side deconqiression. Futther, in view of die anticipated pervasiveness of 
push tedmdogy. efficient handling and recognition of coDq>rBSsed HTML is 
especially i mpoi t a nt. 



SUMMARY OF THE INVENTION 

A mechanism for recogniziiig and processing compressed hypertext 
markup language (HTML) data is described. According to one aspect of the 
present invention, compressed HTML is downloaded by an £^plication by 
employing a protocol intacqttor. 

The application receives a request for a resource located on a remote server that 
contains compressed HTML data. Hie application invokes an appropriate 
protocol interceptor to download the requested resource. The protocol interceptor 
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requests the resource from the remote server by way of a network transfer 
protocol. Compressed HTML data is received by the protocol interceptor. The 
protocol interceptor decompresses the compressed HTML data and provides 
HTML data to the application which may then be rendered by the application. By 
employing a protocol interceptor as an internaediary between a Web server and a 
client-side ^plication, HTML data may be transferred in a compressed format 
from the Web server to the client transparently to the requesting application. 
Advantageously, transferring HTML data in conqtressed format conserves 
network bandwidth and decreases the amount of time required to download Web 
documents. 

Other features of the present inventian will be appatent from the 
acconqianying drawings and from tte detaUed description which follows. 

BRIEF DESCRIPTION OP THE DRAWINGS 

Hie presmt invoiticHi is illustrated by way of example, and not by way of 
limitation, in the flares of the acconq>anying drawings and in which lite 
a&ieace numerals refer to sunilar elements and in whidi: 

Figure 1 is a logical view of a dient/sorva: netwo±. 

Figure 2 is an exanq>le of a con^mter system upon whidi one embodiment 
of the present invraition can be implonented. 

Figure 3 is a block diagram illustrating components of an exeaq>lary 
plication according to one embodimrait of the present invention. 

Figure 4 is a flow diagram illustrating resource request processing 
according to one embodiment of the present invention. 

DETAE^D DESCRIPTION 

A mechanism for recognizing and processing compressed HTML data is 
described. According to the i^ent invention, HTML data may be transferred in 
a c<Hnpressed format from a Web server to a client transparently to the requesting 
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client application by using a protocol interceptor as an intennediary between the 
Web server and the application. For example, when the application encounters a 
resource that satisfies a predetermined condition, the protocol interceptor may be 
called upon to transfer the data from the Web server to the client. The protocol 
interc^tor uses an ^propriate protocol to download the compressed data stream 
and that transfonns the conq)ressed data stream into an HTML data stream that is 
recognizable to the aqpplication. In this manner, the plication need not have 
knowledge regarding fbe data's intramediate storage and transmission format. 
BLather, the application can simply call upon a protocol intoceptor that is 
associated widi the resource and receive HTML data. 

in the following description, for the purposes of explanation, numerous 
specific details are set fordi in order to provide a thorough und^standing of the 
inesent inventioiL It will be qspaimt. however, to one skiUed in die art that the 
present invration may be practiced without some of these specific details. In 
other instances, weU-known structures and devices are shown in block diagram 
form. 

The pres^ invendcm includes various steps, which will be described 
below. The steps of the present invention may be embodied in machine- 
executable instructions, whidi may be used to cause a general-purpose or spedal- 
puipose processcH- programmed with the instructions to perform the steps. 

Inqx>rtantly, while embodiments of the present invention are described 
with referrace to a particular mechanism for recognizing compressed content 
such as inspecting the scheme of a requested URL, for example, those of ordinary 
skill in the art will be aware of equivalent mechanisms. Additionally, 
embodiments of the present invention are described with reference to a particular 
mechanism for processing compressed HTML, such as a moniker. However, 
alternative mechanisms such as plug-ins, helper applications and the like are 
contemplated. Finally, while the present invention may be embodied in a Web 
browser such as Microsoft Internet Explorer, the method described herein is 
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equally applicable to other Web-based applications and browsers such as 
Netscape Navigator™, Lotus Notes™, and others. 

Before describing the novel method of recognizing and processing 
compressed HTML, the client-server model as applied to the Web and the 
conventional method of transmitting and rendering Web documents will briefly 
be discussed with reference to Figure 1 . Figure i depicts a plurality of clients 1 10 
and servers 120 coupled in communication with a network 100. Network 100 
may represent the infrastructiire of a Local Area Network (LAN), an Intranet 
comprising a collection of LANs, a Wide Area Network (WAN) spanning 
geographical areas, or the global web of interconnected computers and computer 
netwoiks tbat make up the Intnnet, for example. An exenqdary client 1 10 
architectuxe is discussed below. 

The process of serving a Web docummt to an Internet user can be 
described in three stqs. The Web browser issues a request for a Web document, 
or more geaoaliy, a "cesonrce" on a specific Web server 120. This request is 
typically in the form of a HTTP Get request which provides die snver 120 with a 
logical address, such as a Uniform Resource Locator (URL), of the requested 
Webdocument. When ^server 120 receives the request, it seardbes its 
docunwnt space for the requested Web dooiment, and transmits the Web 
document in an unccHiqnessed HTML format to the Web browser. Uponrec^pt, 
the Web browso- rendos die Web document as directed by the HTML encoding 
contained therdn. 

AN EXEOMPLARY CUENT SYSTEM 

Referring to Figure 2, a computer system is shown as 2(X). The computer 
system 200 represents an exemplary client 1 10 upon which one embodiment of the 
present invention may be implemented. Computer system 200 comprises a bus or 
other communication means 201 for communicating information, and a processing 
means such as processor 202 coupled with bus 201 for processing information. 
Compiter system 200 fiirlher comprises a random access memory (RAM) or other 
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dynamic storage device 204 (referred to as main memory), coupled to bus 201 for 
storing information and instructions to be executed by processor 202. Main 
memoiy 204 also may be used for storing temporary variables or other intermediate 
information during execution of instructions by processor 202. Computer system 
200 also comprises a read only memory (ROM) and/or other static storage device 
206 coupled to bus 201 for storing static information and instructions for processor 
202. Data storage device 207 such as a magnetic disk or optical disc and its 
corresponding drive may be coupled to bus 201 for storing information and 
instructions. 

Onnputer system 200 can also be coupled via bus 201 to a display device 
221, such as a cathode lay tube (CRT), for displaying infotmaticm to a con^uter 
user. For eckn^e, Web documents, graphics, video clips, and other data types may 
be pieseDted to the vsesr on the display device 221. Typically, an alphanumeric 
input device 222, including alphanumeric and other keys, is coupled to bus 201 for 
comnnmicating infonnaQon and/or command selections to processor 202. Another 
type of user input device is cursor control 223, such as a mouse, a txaddiall, or 
cursor direction keys for communicating direction information and conunand 
selections to processor 202 and for controlling cursor movement ca display 221. 

A ccwnmimication device 225 is also coupled to bus 201 for accessing 
servers via die Ihtemet, for example. The communication device 225 may 
include a modem, a network inter&ce card, or otb^ well known intoiiace devices 
such as those used for cotq>ling to an Ethernet, tokm ting, or otho- types of 
networks. In any event, in fids manner, the conqputer system 200 may be coupled 
to a number of servers via a conventional network mfiastructure, such as a 
company's Intrant and/or the Internet, for exanq>le. 

AN EXEMPLARY APPUCATTON 
Figure 3 illustrates a block diagram of an exemplary q}plication 300. In 
the embodiment depicted, the application 300 may be a Web-based application 
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such as Microsoft Internet Explorer or similar Web browser capable of requesting 
Web documents from servers via HTTP and rendering those Web documents. 

In the embodiment depicted, the application 300 includes a user interface 
(UI) 310, a protocol manager 330, a set of handler classes 320, a protocol map 
360, a set of data handlers 370, a set of native protocol handlers 340, and a 
protocol interceptor 350. Each of these items will briefly be described below, 

A user miay provide input to the ^plication 300, such as an indication of a 
link or URL to which the user desires to navigate through UI 3 10. The UI 310 
may additionally provide visual feedback to the user via the display 221 in the 
fotm of text and/or gr^hic images representing Web documents corresponding to 
resources leqtiested by the user. 

Resource requests from the user are processed by the protocol manager 
330. Li one embodiinent, the protocol manago: 330 detennineswidiKfeis^ 
the protocd inap 360 v^iether or iK>t the requested resource is associated with a 
natively supported protocol such as HTTP. 

If ^ requested resource is associated with a protocol that is natively 
stqiported by the ^application 300, then the resource m^ be downloaded to the 
client upon which the application is executing by a protocol handler from fbt set 
of native protocol handier objects 340. Tixb nativ^y siqsported protocols 
include standard Litemet protocols Oiat the supplication 300 itself knows how to 
process. The protocol associated with a particular resource request refers to the 
predefined iqiplication-level commimications for downloading the resource to the 
client from the remove server. For »cample, the protocol may specify how 
requests and acknowledgments are handled and the structure of cranmunicated 
data. At any rate, Web browsers typically natively support HTTP, Rle Transfer 
Protocol (FTP), Gopher, and other application protocols. Typically, if a particular 
protocol becomes prevalent enough on the Web, later generations of Web 
browsers can be expected to provide native support for such protocol. Therefore, 
it should be appreciated that more or less native protocol handlers may be 
employed in alternative embodiments. 
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If the protocol manager 330 determines no natively supported protocol is 
associated with the resource request, then an appropriate non-native handler from 
handler classes 320 such as a protocol interceptor 350 may be employed. There 
are many ways to implement the protocol interceptor 350, some of which will be 
discussed below. According to this embodiment, handler classes 320 may include 
one or more classes of protocol handlers for protocols that are not supported 
natively by the application 300. For purposes of discussion herein, a "class" can 
be thought of as a piece of executable code while an "object" refers to a particular 
instance of a class. 

To facilitate the locatioa of an ipptopiista handler class corresponding to 
a particular protocol, a mumping of protocols to handler classes may be provided 
by a protocol 360. Altemativdy, the mapping may use one or more portions 
of the URL to niq> to paitieular handler classes. At any rate, in this manner, 
when no native sapptat is provided for a paiticolar protocol, the qiplication 300 
may instantiate (e.g., make an instance of) an appropriate handler fiom die set of 
handler classes 320 with refeience to the protocol xoap 360, for example. Jn one 
«nbodimrait, the jnotocol map 360 may be iiiipl«nented with tibe Windows™ 
Registry. However, the protocol 360 is not limited to such a fUe. Allthatis 
needed is a mechanism for associating protocols or groups of resources with a set 
of instructions such as a handler for processing data acceding to the 
conesponding protocol. Processing, in this context, Qrpically involves 
downloading an input data stream from a saver and transforming the input data 
stream from its (niginal data type into a data stream ^ is recognizable by the 
Implication 300, if necessary. In alternative einbodiments, this 
association/mapping may be maintained in a local database or any other file so 
long as the protocol manag«- 330 is configured ^ropriately so as to find it. 

When the UI 310 receives the requested resource from the protocol 
manage: 330, for purposes rendering the Web document, the application 300 may 
empl<^ the data handlers 370. Web browsers ^ically natively support Graphics 
Interchange Fonnat (GIF) and Joint Photogrq)hic Experts Group (JPEG) graphic 
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files which are commonly used for inline images. The data handlers 370 may 
include one or more data handlers for rendering HTML, GIF, and/or JPEG files, 
for exan^ile. 

Uniform Resource Locator (URL) syntax 

Before describing some exemplary handler classes, it may be helpful at 
tins point to briefly describe the syntax of a URL. URLs follow the syntax 
described in Request for Comments (RFC) 1738, Uniform Resource Locators 
(URL), December 1994. Accwding to RFC 1738, a URL contains the name of 
the "scheme" being used (e.g., hap, ftp, gopher, etc.) followed by a colon and 
thai a string, the "scheme-specific part" whose interpretation depends on the 
schrane. URLs are, therefore, written as follows: 

<sc]ieme>:'«ch«iie-specafic pait> 
For exaniple, the PointCast. Inc. Web site is located at the foUowing URL: 
"fattp://www.pointcastcom". Hie scheme is 'Itt^** and the scheme-specific part 
is "www.pointcast.c(»n". 

Resources having the same data type may be identified by grouping 
resources of a particular data type within a common scheme. Fotexampls, 
according to one enibodiment of the presmt inventi<m, the scheme "pen" (short 
for PointCast Netwcak) may be used to identify the conipiessed HTML data typt. 
Thus, the file identified by the URL "pcn-7<path>/<filename>", for exanqsle. 
would be known by the protocol interceptor 350 to contain compressed HTML 
simply by referring to die scheme of the URL. 

Assuming the naming convention of "pen" for the sdMme of conipressed 
HTML has been established, an i^roptiate handler class that knows how to 
commimicate with the server upon which these files are located may be added to 
the handler classes 320 and registered with the protocol map 360 to be associated 
with the "pen" scheme. Subsequently, requests received by the ^plication 300 
for resources associated with the "pen" scheme will be routed to the appropriate 
handler by the application 300. The handler will be responsible for downloading 



wo 99/27460 



PCT/US98/23835 



-10- 



the requested file, decompressing tiie compressed HTML data stream, and 
providing an HTML data stream to the application 300. In this example, the 
choice of "pen" is an arbitrary one, therefore it should be appreciated that other 
schemes may be employed. 

Additional mappings that are contemplated may employ a standardized set 
of types such as Multipurpose Internet Mail Extensions (MIME) types. 
Alternatively, r^urces having the same data type may be identified with 
reference to the scheme-specific part of the URL such as the file extension. For 
example, a ".pen" octension may be useful for identifying a conqnessed HTML 
file. 

It is worth mentioning that the particular compression algorithm erqployed 
on the servers 120 for producing ctnnpressed HTML files is unimportant so long 
as the clients 110 use a conesponding deccnqxession algcnailiin. 

EXEMPLARY HANDIER CLASSES 
Many possibilities exist for implementing the handle: classes of the 
present invention fen- purposes of recognizing and processing compressed HTML. 
For exanqde, help^ spidicattons, plug-ins, full protocol handles, monikns or fbc 
like may be employed. Helper plications (also referred to as external viewers) 
are programs external to the Wd} browser that are used to render data types that 
the browser doesn't recognize natively. Helper {q>plications typically display the 
file s^arately from the Web browser. 

Plug-ins are software programs used in conjunction with Web browsers 
that are responsible for both data delivery (dovniload) and display. 

Full protocol handlers are client-side objects instantiated by Web-enabled 
applications to allow the transparent delivery of Internet content. Similarly, a 
moniker is a client-side object that encapsulates a data item's name, location, and 
the operations required to open it. For example, a moniker might contain a file 
name or a URL. A moniker may be thought of as a protocol handler that gets in- 
process handling rather than launching a separate process. Monikers support an 
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operation known as binding, which is the process of locating the object named by 
the moniker, activating it or loading it in memory if it isn't already there, and 
letuming an interface pointer to it. 

To facilitate the routing of resource requests to custom URL protocol 
handlers, it is desirable to form an association between the resource and the 
handler class. In Microsoft® Internet Explorer™ a mechanism is provided for 
defining new protocols with the Asynchronous Pluggable Protocols Application 
Program Interface (API), which allows specific protocol schemes, for example, to 
be mapped to a handler class. This type of mapping may be accomplished in a 
Dumber of ways including registration of an asynchronous pluggable protocol, 
registration of a pluggable name-space handler, and registtiation of a MIME filter. 

An asynchronous pluggable protocol (handler class) may be registered in 
the protocol nap 360 (e.g., Windows Registry). Asynchronous pluggable 
protocols allow attempts to navigate to URLs with a specified scheme, such as 
hxtp, ftp, and ib& like, to be routed to a custom URL protocol handler registered in 
the protocol map 360 (e.g., a system registry, Wmdows Registiy, or the like). 
Therefore, after the handler has been registered, the handier will be used for any 
URLs containing the specilSed scheme. 

A pluggable name-space handler can be set up to handle one or more 
specific patterns for a givra URL sdieme. Whai(nieoftheq>ecifiedpattnnsls 
found in a URL scheme-specific part of the ^proiniate scheme, the handler is 
used rather than the default protocol for the scheme. A pluggable name-space 
handler may be used to identify compressed HTML files having a predetramined 
file extension, or kqr phrase in the path, for exanq)le. 

A MIME filter may be rpgistoed for a particular pattern in the MIME 
content-type header field. Hie handler may be used to manipulate the 
conq>ressed HTML data stream it receives and return a deconqnessed HTML data 
stream for received MIME messages having the specified content-type. . 
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RESOURCE REQUEST PROCESSING 
Resource request processing will now be described with reference to 
Figure 4. According to the embodiment depicted, the flow of the resource request 
processing is determined based upon the resource request itself. Several 
mechanisms for determining the appropriate protocol handler have been 
discussed, for example, the appropriate protocol handler may be determined with 
reference to the scheme of the URL or the extension of the file being requested. 
At step 405, a lesouice request (e.g., a request for a file, a database record, etc.), 
typicaUy in the fona of a DSL including zero or more parametets, is received by 
the application 300 in the UI 310, for example. 

At step 410, as described above, subsequent processing may be 
detennined based upon the resource request (e.g.. the URL). The sqipropriate 
protocol handler for downloading the requested resource to the client may be 
detennmed with refisrrace to the scheuM of the URL, the MIME Qrpe associated 
with the server' s resptxose, or other similar mechanisms, for examide. According 
to one embodimaat, the appropriate handler is determined by searching the 
protocol map 360 for a scheme Oat matches die scheme of the URL of step 405. 
In alternative embodiments, a mapping of file extensions or MIME ^ypes to 
handler classes may be maintained in the protocol map 360, as described above. 

Those of <ndinaiy skill in the ait will q)preciate, in alternative 
embodiments, such as those employing plug-ins, help^ ^jplications, or 
equivalent software programs, rather than searching the protocol map 360, the 
protocol manager 330 may look to a local directory where it expects to find an 
ajqirqpriate program to handle the resource request. In any event, acctnxiing to 
the embodiment depicted, if the protocol handler corresponds to a native protocol 
handler then processing continues with step 415. Otherwise, if the protocol 
handler is one for processing compressed HTML, then processing continues with 
step 425. 

At step 415, native protocol handler processing is perfbnned, as described 

above. 
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At Step 425, the appropriate handler, identified at step 410, is instantiated. 
Preferably, the handler object, such as protocol interceptor 350 is an 
asynchronous task which allows the application 300 to continue other processing 
while downloading of the requested resource proceeds. This objective may be 
met by employing a URL moniker, an asynchronous moniker that may return 
from a binding call before the bound object is conq)letely ready. In this manner, 
execution of {plication 300 may continue while the object binding completes. A 
URL monilcn allows a client program such as application 300 to create a moniker 
whose data is referenced by a URL. Alternatively, ihe handlca- may be 
implemented as an asynchronous pluggable protocol. As described above, 
asynchronous pluggable protocols allow attempts to navigate to URLs with a 
specified scheme, to be rooted to a cnstom URL lootocol handler. 

At step 430, the lesoutce request is passed to the handler. Alternatively, 
this may be performed when the handler is instantiated in st^ 425. At step 435, 
the handler determines if tbe requested resource is present in a local cache. If so. 
assuming the resource is unchanged at the source, at step 440, the resource may 
be retrieved firom the cache rather than having to make a request to a remote 
servw.forexanqde. 

At step 445, the handler transmits a request to the remote server, such as a 
HTTP request, corresponding to the resource request. At step 450, HTTP 
response data is received in the form of compressed HTML. 

At step 455, the handler decompresses the data received in response to the 
request of step 445. Importantly, it may take more than one HTTP response to 
receive all the data corresponding the HTTP request. If this is the case, then 
decompression may be performed upon receipt of each subsequent HTTP 
response. 

At step 460, the deconqjressed HTML data is provided to the application 
300. According to one embodiment, the protocol interceptor 350 supports 
streaming of the decompressed HTML data. That is, the protocol interceptor 350 
allows the application 300 to begin rendering the HTML data before the entire 
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fUe and/or any embedded content have been completely downloaded and 
decompressed. Since rendering of the HTML data can begin earlier, streaming 
has the advanta^ of reducing the perceived download time associated with 
viewing Web docmnents. In other embodiments, the protocol interceptor 350 

simply provide the decompressed HTML data to the application 300 when 
•downloading and decompression are complete. 

At step 465, the plication 300 renders the HTML data in a well known 
mannea* osing one of the native data handlers 370, for example. 

In the foregoing specification, tfie invention has been described with 
refeiMice to specific enOxxiimBnts thraeof. It will, however, be evident that 
various modifications and changes may be made thereto without dq>arting ftom 
the broader spirit and scope of the invention. The specification and drawings are, 
accoidingly, to be legaided in an illustrative rather than a zestticti ve sense. 
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CLAIMS 

What is claimed is: 

1. A method of rendering compressed hypatext markup language (HTML), 
the method conning the steps of: 

an applicati(Mi receiving a request for a resource located on a remote 

server that contains conqnessed HTML data; 
die implication downloading the resource by invoking a protocol 

interceptor; 

the protocol intoceptor requesting the resource from the remote server by 

way of a n^otk transfix protocol; 
the protocol interceptor receiving compressed HTML data; 
the protocol interceptor providing HTML data to the plication £ar 

disph^ 1^ decompressmg the compressed HTML data; and 
die application rendering the HTML data. 

2. The method of claim 1, fiother including the step of selecting the protocol 
interceptor &om a grotp of one or more protocol interceptors. 

3. The method of daim 2, \iAierBin prior to the step of selecting the protocol 
interceptor fiom a group of one or more protocol interceptors, the 
supplication perfonns the step of determining whether the resource is 
associated with a nadvely recognized protocol. 

4. The method of claim 2, wherein the request for the resource comprises a 
Uniform Resource Locator (URL), the URL including a name of a scheme 
and a scheme-specific part. 

5. The method of claun 4, wherein die step of selecting die protocol 
interceptor £com a group of one or more protocol interceptors is based 
upon the scheme. 
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6. The method of claim 5, further including the step of registering the 
protocol interceptor as an Asynchronous Pluggable Protocol. 

7. The method of claim S, wherein the network transfer protocol conqirises 
Hypertext Transfer Protocol (HTTP). 

8. The method of claim 5, wherein the network transf^- protocol comprises 
File Transfer Protocol (FTP). 

9. The method of claim 5, wherein the networic transfer protocol comprises 
Goidier. 

10. The method of claim S, wherein the network transfer protocol courses 
Siitqple Mail Transfer Protocol (SMTP). 

11. Hie mediod of claim 4. wherein the step of selecting the protocol 
iateicqptor from agnnq) of one or mm protocol interceptors is based 
upon the scheme-qtedfic part of the URL. 

12. The method of claim 1 1, further including the step of registering the 
protocol interceptor as a Pluggable Name-Space Handler. 

13. A caapata system compiising: 

a Storage device having stored therein a protocol intercq)t(Hr for 

downloading resources having contained therein conqiressed 

HTML data; and 
a processor coupled to the storage device for executing the protocol 

interceptor to download a resource located on a remote server, and . 

to generate HTML data, where; 

the resource located on the remote server is downloaded from the 
remote server by a network transfer protocol, and 

the HTML data is generated by decompressing the compressed 
HTML data in the resource. 
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14. A machine-readable medium having stored thereon data representing 
sequences of instnictions, said sequences of instructions which, when 
executed by a processor, cause said processor to perform the steps of: 
receiving a lequest for a resource located on a remote server that contains 

compressed hypertext markup language (HTML) data; 
downloading the resource by requesting the resource from the remote 

serv^ by way of a netwodc transfer protocol; 
receiving compressed HTML data; 

providing HTML data by decompressing the conqnessed HTML data; and 
i«idaing die HTML data. 

15. The machine-readable medium of claim 14, wherein said sequences of 
instructions when executed by a processor furtbei cause said processor to 
perform Ihe stq> of selectitig a protocol interceptor ficom a group of one or 
more protocol intmceptois. 

16. The madiine-ieadable medium of claim IS, wherein prior to die step of 
selecting a protocol interceptor fiom a group of one or more protocol 
inteicq)tors, said sequences of instracticHis causing said processor to 
perform the stq> of determining whether the resource is assodated wiUi a 
natively recognized protocol. 

17. The machine-readable medium of claim 15, wherein the request for the 
resource comprises a Uniform Resource Locator (URL), the URL 
induding a name of a scheme and a sdieme-spedfxc part 

18. The machine-readable medium of claim 17, wherein the step of selecting a 
protocol intoceptor firam a group of one or more protocol interceptors is 
based upon the scheme. 

19. The madiine-readable medium of claim 1 8, wherein the network transfer 
protocol comprises Hypertext Transfer Protocol (HTTP). 
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20. The machine-readable medium of claim 17, wherein the step of selecting a 
protocol interceptor from a group of one or more protocol interceptors is 
based upon the scheme-specific part of the URL. 

21 . A method of lendoing compressed hypertext markup language (HTML), 
the method comprismg the st^ of : 

providing a protocol intoceptor for use widi resources associated with a 
scheme, ttie scheme indicating the resource includes compressed 
HTMLdata; 

an applicadan receiving a request for a resource assodated wi& the 
scheme; 

the application invokmg the protocol intercqttor widi a resource locator 

identifying the resource; 
the protocol interceptor requesting the resource fiom a source identified 

by the resource locator by way of a networic transfer protocol; 
^ protocol intoceptor receiving conqiressed HTML data; 
the protocol intoceptor providing HTML data to the a^llcation for 

di^lay by deconqnessing the con^ressed HTML data; and 
the application rendering the HTML data. 

22. The meAod of daim 21. the mdfaodfiuther including the step of the 
plication determining die resource is not associated with a natively 
recognized protocol based upon the scheme. 

23. The method of claim 22, wherein the step of the application determining 
the resource is not associated with a natively recognized protocol based 
upon the schnne further indudes the stop of searching a protocol zm^. 

24. The me&od of claim 2 1 , further including the step of selecting the 
protocol 'mterceptOT from a group of one or more protocol interceptors. 
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A method of providing hypertext markup language (HTML) daia. to an 

application, the method comprising the steps of: 

receiving a request from an application for a resource, the request being 

accompanied by a resource locator; 
requesting the resource from the source identified by the resource locator 

by way of a netwotk transfer protocol; 
receiving a compressed steam of data; 

generating HTML data by decompressing the compressed stream of data; 
and 

streaming the HTML data to the plication for displ^. 

The method of daim 25, wherein the af^lication is a Wd)-based 
i^iicatioiL 

The mediod of claim 25, wherein the application is a Web browser. ' 

The method of claim 25, wherein the netwoik traosfer protocol comprises 
hypntext transfer protocol (HTTP). 

The method of claim 25, wherein the resource comprises an Internet 
resource. 

The metiiod of claim 25, wherein the resource comprises an Intranet 
resource. 

The method of claim 25, wherein the protocol iatesceiptor coixq)rises a 
moniker. 

The method of claim 25, wherein the protocol interceptor con:^)rises a 
helper application. 



The method of claim 25, wherein the protocol interceptor comprises a 
plug-in. 
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34. The method of claim 25, wherein the protocol interceptor comprises an 
asynchronous pluggable protocol handler. 
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